Network monitoring systems for medical devices

ABSTRACT

A ventilator monitoring system is described for monitoring a plurality of ventilators. In one embodiment, a server including a dedicated ventilator application program for each type of ventilator, monitors a plurality of heterogeneous ventilators over a wireless network.

REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.10/984,186, filed on Nov. 8, 2004, which is a continuation of U.S.patent application Ser. No. 09/791,334, filed on Feb. 23, 2001, now U.S.Pat. No. 6,839,753, the entire disclosures of each of which are herebyincorporated by reference herein.

TECHNICAL FIELD OF THE INVENTION

This invention relates in general to network monitoring systems formedical devices, more particularly, to network monitoring systems thatcollect data from heterogeneous devices for display at a centralmonitoring station.

BACKGROUND

Remote medical monitoring systems provide the advantage of monitoring aplurality of medical devices connected to one or more patients from asingle site. In a health care facility, a single monitoring systemstation permits simultaneous monitoring and interaction with remotemedical devices located, for example, in a patient's hospital room.Network monitoring systems provide uniform and continuous patientmonitoring while reducing the number of trained health care personnelneeded to monitor and interact with each medical device.

Remote monitoring systems having numerous disadvantages are currentlyused in health care facilities. These prior art systems typicallyrequire manual entry of data into a patient's record. Waveform data orsimilar data is typically generated from the network system as a hardcopy and manually entered by cutting and pasting into the patient'smedical record. Manual entry of data into a patient's medical record islikely to introduce transcription errors in the patient's medicalrecord.

Some prior art monitoring systems are capable of monitoring devices ofthe same make and model manufactured by the same company. Typically,health care institutions purchase medical devices, such as ventilators,from a number of different manufacturers. As currently known in thefield of respiratory ventilators, in order to monitor a ventilator froma remote location, a remote monitoring system is required for eachventilator make and model. Consequently, a monitoring station andadditional personnel are required to monitor each ventilator type. As aresult, efficiency, which would otherwise be introduced by having anetwork monitoring system that monitors heterogeneous ventilators, isdiminished.

SUMMARY OF THE INVENTION

The network monitoring system for medical devices according to theinvention monitors and collects data, such as medical device settings,measured patient values, alarm conditions, and other data, fromheterogeneous devices and displays the data at a central monitoringstation. The display of collected data uses web technology so that thedata can be displayed on any client computer connectable to aninstitution's intranet. In a further embodiment of the invention,trending data of various patient parameters is gathered so that userscan view the patient's recent history. A log is kept of the importantevents that occurred on the medical device and of important patientparameters to provide diagnostic information to caregivers such asnurses, technicians, and physicians.

In one embodiment of the invention, each medical device has its own dataacquisition service application on a server that either listens forunsolicited data or actively polls data from the medical device. Theseapplications are optimized to collect data and load it into the databasequickly. In one embodiment of the invention, the medical device is aventilator.

The database, in one embodiment, is Open Database Connectivity (ODBC)compliant so that the database is accessible to the server side webpages. The server side web page provides tables that store device data,configuration data, customization data and device-specific data. Queriesmade to the database in one embodiment are stored to speed upcomplicated query functions such as table joining.

In one embodiment of the invention, the data obtained by the dataacquisition service application on the server is displayed by a webbrowser or a client connected or connectable to a hospital intranet. Webpages are generated by executing code on the server using data stored inthe database and outputting standard HTML.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an embodiment of the invention.

FIG. 2 is a more detailed block diagram of the embodiment of theinvention shown in FIG. 1.

FIG. 3 is a diagram of a listener application according to oneembodiment of the invention.

FIG. 4 is a flow chart of one embodiment of the operation of thelistener application of FIG. 3 according to the invention.

FIG. 5 is a flow chart of one embodiment of the operation of the loadthread application of FIG. 3 according to the invention.

FIG. 6 is a flow chart of the operation of an embodiment of a parseraccording to one embodiment of the invention.

FIG. 7 is a diagram of a pollster application according to oneembodiment of the invention.

FIG. 8 is a flow chart of the operation of one embodiment of thepollster application of FIG. 7 according to one embodiment of theinvention.

FIG. 9 is a flow chart of one embodiment of a connection request eventaccording to the invention.

FIG. 10 illustrates embodiments of data tables according to theinvention.

FIG. 11 illustrates a Matrix View screen display according to oneembodiment of the invention.

FIG. 12 illustrates a List View screen display according to oneembodiment of the invention.

FIG. 13 illustrates a Detail View screen display according to oneembodiment of the invention.

DETAILED DESCRIPTION OF THE INVENTION

In brief overview and referring to FIG. 1, a system constructed inaccordance with the invention includes a medical device 20 such as aventilator, connected to a network access device 26 such as a wirelesstransceiver. The network access device 26 communicates with a network 30such as an 802.11 wireless Ethernet® local area network. A server 36,such as the Bernoulli server manufactured by the CardiopulmonaryCorporation Milford, Conn., executing an application program 50 is alsoin communication with the network 30 through a network access point 26′through a router 40 by way of the same network 30 or a different network30′. The server 36 communicates with a database 44 and a user accessesinformation on the server 36 using a browser 48 on a client computerthrough a network link 30″ which may or may not be the same as theaforementioned networks 30, 30′.

In operation, the Bernoulli server 36 requests information from themedical ventilator 20 generally through the router 40. Data obtainedfrom the medical ventilator 20 is stored in the database 44. When a userwishes to access ventilator data from the medical ventilator 20, theuser uses a browser 48 to read the ventilator files stored in thedatabase 44.

In more detail and referring also to FIG. 2, in one embodiment themedical ventilator 20 is connected, via an RS232 serial port, to anetwork access point 26. The network access point 26 converts the serialRS232 data available from the medical device 20 to a TCP/IP protocolcompatible formal for transmission over the network 30. In oneembodiment, the network access device 26 converts the serial data toEthernet® data and sends the Ethernet® data to an Ethernet® hub fortransmission to the server 36.

In another embodiment of the invention, the network access device 26 isa wireless Ethernet® transceiver which not only converts the serialRS232 data to the correct protocol for a wireless Ethernet® network butalso converts the data to radio frequency data which is then broadcastgenerally over a limited area. The radio frequency data is received by awireless network access point 26′ which converts the radio frequencydata back to TCP/IP data on a network connection and sends the data tothe appropriate data acquisition application 50 on the server 36.Conversely, the network access point 26′ also converts data from theserver 36 to a wireless TCP/IP protocol which is transmitted via thewireless network 30 and received by the network access device 26. Thenetwork access device 26 then converts the received radio frequencyinformation to serial RS232 data for use by the medical ventilator 20.

According to the invention, a dedicated data acquisition application 50on the server 36 is used for each medical ventilator type 20. That is,generally each brand of ventilator will have its own protocol and willhave a separate application program 50. Each data acquisitionapplication 50 is in part a listener program 50′ specifically programmedto communicate with the medical ventilator type 20. Data acquisitionapplications 50 that send commands to prompt for data include what arereferred to as pollsters 50″. Since the listener application 50′ and thepollster application 50″ typically are running, in one embodiment theyare written as a service application.

In one embodiment, according to the invention, referring to FIG. 3, alistener application 50′ listens for data at a known User datagramprotocol/Internet protocol (UDP/IP) port. The UDP protocol allows thedata to go in one direction from the medical device 20 to the server 36without the need for an established socket connection. In anotherembodiment, the time spent listening by the listener application 50′ onthe known UDP/IP port is maximized by using a multithread programexecution approach. Referring to FIG. 3, for this embodiment, twothreads are utilized: a listen thread 100 waits for data on the networkaccess port 104 and a load thread 108 processes the received data andstores it in the database 44.

In this embodiment, referring to FIG. 4, the listen thread waits in STEP300 for one of three events to occur. The three events are the shutdownevent (STEP 310), the data ready event (listen for socket data) (STEP320), and the minute timer event (STEP 330). The shutdown event (STEP310) is triggered when the service Application Protocol Interface (API)requests to shutdown the listener application (STEP 340). The data readyevent (STEP 320) is triggered when data is available on the UDP/IPnetwork port so that data can be read (STEP 350) and put into a messagequeue 110 (STEP 360).

The minute timer event (STEP 330) is unlike the other two events in thatit is a periodic event triggered once per minute. Each time the minutetimer is triggered, the current values or the configured parameters thatare set for the ventilators 20 are appended to a table of data (STEP370), the trend data table, described below, with a time stamp. Anytrend data older than a configured time (for example, a default of 72hours) is purged from the trend data table (STEP 380). Also any medicalventilator data in the active device data table described below olderthan two minutes is purged to prevent possible user misinterpretation ofthe data. In a particular embodiment of the invention, each time theminute timer is triggered (STEP 330), there is a check to see if it istime for a scheduled “snapshot” (STEP 390) of the active data to berecorded. A “snapshot” is the action of copying all of a medicaldevice's data from the active data table and placing it into a snapshottable, described below, with a time stamp. Snapshots are used to trackthe medical device state at the time of important events (STEP 400) forreporting purposes.

Referring also to FIG. 5, according to the invention, once the listenthread 100 receives data, the load thread 108 waits for the data toarrive in the message queue (STEP 410). Once the data has been receivedin the message queue, all values are analyzed from the data (STEP 420)and the name of the value is determined (STEP 430) If the value exists(STEP 440), and has not changed (STEP 460), no changes are made and theloop is continued. If the value does not exist (STEP 440), a value iscreated (STEP 450) and the loop is continued. If the value has changed(STEP 460), the value is updated for the device (STEP 470) and the loopis continued. After all of the values are processed STEP 420 adjustmentsare made to the data. If a setting was changed on the ventilator or analarm was triggered (STEP 490), all active data is transferred to thesnapshot table with a timestamp (STEP 500). In one embodiment, an alertis sent by Simple Mail Transport Protocol (SMTP) or telephony (STEP 521)to a remote device such as a pager. After all processing is finished,the Just_Changed_flags are cleared (STEP 531).

In more detail once the message is received by the listen thread, theindividual medical ventilator values are parsed out of the data streamby the parser 60 (FIG. 2). Referring also to FIG. 6, in one embodiment,for example, data received from the medical ventilator 20 (STEP 415)includes a single line with four ASCII values separated by spaces andterminated with a carriage return (“500 020 030 004”). The name of eachvalue is determined (STEP 600; STEP 601; STEP 602; STEP 603) by usingthe data protocol of the medical ventilator, for loading into the activedata table of the database 44.

The data response may contain for example, tidal volume, oxygen setting,a high pressure limit and an inspiration time and may be associated withthe following database names: chTV, stFI02, stPPAWhi, stITIME. Thedatabase names and the medical device identification, for example, DevA,are used as keys in the active data table described below. According tothis embodiment of the invention, the first row to be added to thedatabase in the active data table (STEP 650) in the above example is:DevA, chTV, 500. A new row is created in the active data table for thedevice value if the device value does not already exist (STEP 440). Nochanges are made if the device value is the same as the one already inthe table. The device value is only updated (STEP 470) if it isdifferent from the value already in the table (STEP 460).

Any adjustments (STEP 480) to the device 20 that need to be made aredone once all the data has been parsed and loaded. Examples ofadjustments (STEP 480) include scaling the inspiration time down tohundredths of seconds. If the adjustment requires checking the values ofmultiple parameters, a temporary device value name may be used whenloading this data. The adjustment process stores the value into thefinal device data name to avoid flickering in the displays. For example,the adjustment process might load the inspiration time value of 004 withthe temporary name of sxITIME during the loading process (STEP 603),check the ventilation mode value (STEP 604), and if Mode=Pressure, savethe value of 0.04 with the stITIME name during the adjustment process(STEP 605).

According to one embodiment of the invention, the monitoring application50 can request that data be sent by the ventilator 20 using a pollsterapplication or pollster portion 50″ of the device application 50. Thepollster application 50″ sends commands 64 to the medical device 20 overTCP/IP socket connections to elicit data responses. The socketconnections are tracked in a connection list so that the connection canbe held open from command to command. The pollster application waits forconnection request at a predefined or well known TCP/IP port. When themedical device 20 sends a connection request to that port, the pollsterapplication 50″ makes the connection by way of another random port usingthe standard TCP/IP “accept” functionality.

In one embodiment of this application, referring to FIG. 7, the dualthread approach is also used. A polling thread 400 and a load thread 410are executing in the pollster application 50″. Referring to FIG. 8, inone embodiment of the invention, the polling thread waits (STEP 600) forone of five events to occur. The first three of the five events are thesame as in the listen thread described above: the shutdown event, dataready event (listen socket data), and minute timer event.

In this embodiment, referring to FIG. 8, the polling thread waits inSTEP 609 for one of the five events to occur. The shut down event (STEP610) is triggered, like in the listen thread described above, when theservice Applications Protocol Interface (API) requests to shutdown thepolling application (STEP 640). The data ready event (STEP 620) istriggered either when data to be read is available on the UDP/IP port orwhen there is notification that the socket connection has been broken(STEP 627). When data is available to be read (STEP 651), the data isappended to the message queue (STEP 660).

The minute timer event (STEP 630) is a periodic event triggered once perminute. Each time the minute timer is triggered, the current values orthe configured parameters are appended to a table of data (STEP 670),the trend data table described below, with a time stamp. Any trend dataolder than a configured time (for example, default of 72 hours) ispurged from the trend data table (STEP 680). Also any device data in theactive device data table, described below, older than two minutes ispurged to prevent possible user misinterpretation of the data. In aparticular embodiment of the invention, each time the minute timer istriggered, there is a check to determine if it is time for a scheduled“snapshot” of the active data to be recorded (STEP 690). Snapshots areused to track the medical ventilator state at the time of importedevents (STEP 700) for reporting purposes.

Referring also to FIG. 9, in addition, the polling thread 400 also waits(STEP 595) for a connection request event (STEP 615) (connect socketdata) and a polling event (polling timer) (STEP 635). The connectionrequest event (STEP 615) is triggered when a medical ventilator 20requests a socket connection using the well known TCP/IP Port for thisspecific application 50″ (STEP 612). The connection, once made, isstored in a connection list (STEP 625). A new entry is made in a devicelist table in the database 44 the first time that a response is receivedby the application program 50 from a ventilator. The medicalventilator's IP address is used to create a unique medical deviceidentification in the table. Commands or polls are sent to eachestablished connection once per second (STEP 635).

The polling event is triggered ten times a second so that commands(polls) can be spaced apart in a random pattern to reduce thepossibility that many requests will be sent by the various applicationprograms at the same time thereby interfering with access to thenetwork. Commands are not sent if the data response from the device(STEP 655) has not been received from the last command sent. Theconnection stops waiting after three such missed poll events and then isclosed.

Referring now to FIG. 10, in more detail, there are four different typesof tables in the database: Device Data Tables 500, Device ConfigurationTables 510, Customization Tables 520, and DeviceSpecific Tables 530. TheDevice Data tables 500 hold data acquired from the medical devices 20.There are tables for holding the latest device values 502, devicesnapshot information 504, trending data 506, and a record of settingchanges and alarm events 508. A Just_Changed_flag 509 is set (STEP 531)within the table row when data is updated in the device data table. Thisflag 509 allows queries to determine if either a setting has justchanged or alarm condition has just occurred. When one of theseconditions is met, a snapshot of the active data is saved into thesnapshot table 504 (STEPS 400 or 700, FIGS. 4 and 8, respectively). Anew entry is appended to the log of events table 508 marking this event.Remote alerts can be sent (STEP 521) to numeric or alphanumeric pagerswhen specific alarms occur. The alarming medical ventilator 20 isassociated with a patient and the patient is associated with a pagerbefore a remote alert can be sent. The Just_Changed_flag 509 is cleared(STEP 531) for all the active device data after all of the checks havebeen made.

The Device Configuration tables 510 store the information about theinstitution like the list of beds, patients, users, etc. The history 512of the mappings of devices, beds, and patients is stored in theconfiguration table. This table is important when recovering patientinformation after changes have been made. The Customization tables 520hold information that controls the appearance of most of the userinterface. All customizations are stored together to facilitate futureexpansion of the system. Customizations are organized by Group 522,Subgroup 524, and DeviceType 526. The customizations are stored infields that have generic names (Param1, Param2 . . . ) so the databaseform used to enter the data must operate in conjunction with the webpage that runs the query in order to correctly interpret the values. TheDeviceSpecific tables 530 store information specific to a medical devicetype used for data acquisition. There are tables to mark the values thatare to be trended 532 and tables to hold the descriptions of alarms,settings, and measured values 534.

Data is extracted from the database 44 using Queries. Queries have beendeveloped to speed the cases where these tables must be joined to accessthe data. For example, there is a query that combines the headerinformation in the Snapshot table with the data in the Snapshot Datatable. Queries are also used to hold business rules like determiningwhen to take a snapshot because an alarm condition has just occurred.There are some stored procedures, or action queries depending on thedatabase technology, used to manage the TrendData table.

Queries are made to the system through the web software 71. In oneembodiment, for example, there are three main parts of the userinterface 70: Monitoring, Reporting, and Administration. These functionsare displayed as ‘Monitor’, ‘Report’, and ‘Administer’ buttons,respectively, at the bottom right side of the screen. The Monitorscreen, for example, is arranged to allow the user to view informationon all patient beds, or groups of patient beds, simultaneously, with theoption to view more detailed information on any individual patient bed.The Monitor screen provides information such as patient settings,measured values, and alarm values. The Report screen, for example,allows the user to choose from Trends, Log of Events, Snapshots, etc. toview. After one of these reports is chosen, the user is taken through aseries of screens to set up the parameters necessary to see thespecified report. The Administration screen, for example, allows theuser to add, remove, or change the status of patients and medicaldevices on the network.

In more detail, three different views are available to the user throughthe Monitor screen: the matrix view 750, the list view 760, and thedetails view 770. Referring to FIG. 11, in one embodiment Matrix Viewscreen 750 is primarily used at a central monitoring station. Thisscreen 750 is filled with a matrix displaying the status of allconfigured beds 751 a-751 n, generally 751, including beds withoutassigned patients. The number of columns in this matrix may be adjustedfor optimal viewing. In one embodiment, no more than twenty beds 751 aredisplayed on the screen 750 at once. If there are more configured beds751 than can fit on the screen, then tabs (not shown) will appear on thescreen to select from configured groups of beds; e.g., view all of theNICU beds, SICU beds, or Step Down beds. In one embodiment, the userinterface 70 is a web page.

Each bed 751 is displayed in its own web frame cell 752 a-752 n(generally 752) with a border, and parameter settings are displayed ifthere is an assigned patient and medical ventilator. In one embodiment,the displayed information as well as the border color is medicalventilator dependent. The server side code looks in the customizationtables 520 for information about which device data to display for theassigned medical ventilator. This information includes for example,titles, units, and most importantly the data name in the vent datatable. The device data is then looked up in the vent data table,combined with the title and units, and then sent to the client webbrowser 48. In a particular embodiment, if there is an alarm conditionon the device, the border will change to bright red and the text of thealarm will be displayed. In a further embodiment, if the alarms have notbeen silenced on the device, an audible alarm will sound. The contentsof each bed web frame 752 are refreshed every two seconds.

Whereas the matrix view web page 750 with its multiple frames andfrequent refreshes requires more bandwidth than is commonly availableover dialup lines, the list view web page 760, illustrated in FIG. 12,is optimized for slow connections. In one embodiment, the list view page760 has a single frame displaying information only about the active beds751. Much more information is displayed for each bed 751 in the listview 760 as compared to the matrix view 750, which reduces the need togo to the details view 770. The user is able to display a more detailedview by clicking on the bed title, which splits the screen in the sameway as the matrix view.

If the user clicks anywhere within a web frame cell 752 on the matrixview web page 750, i.e. selects a patient bed 751, then a web page 760with two different sections will appear. In one embodiment, the topsection of the screen will display a small version of the matrix viewweb page 750 while the bottom section will display detailed informationabout the selected bed.

The detailed view web page 770, illustrated in FIG. 13, for example, isdivided into five different sections: title, settings, simple settings,other measurements, and alarms. The title section identifies the bed andpatient and has the ability to send an alert to a remote user, allow theuser to view this detail section 770 as a full screen, or to print thepage.

In one embodiment of the detailed view 770, the settings section isgenerally set up as a table with five rows: Primary Setting, SecondarySetting (if supported by the medical device), High Alarm Limit,Measurement, Low Alarm Limit. Each primary setting is labeled with atitle and units. If the medical device has dual modes, then thesecondary settings are displayed below the primary settings. Each columnshows information about one setting with any related measured value andalarm limit. The alarms and measurements are displayed proportionally tothe maximum setting value. If the measured value is outside the alarmlimit, then the alarm background will be highlighted in red to drawattention to it. Three rows will be used if there is no maximum valueset for the setting and no secondary settings.

The simple settings section displays those settings that have no relatedalarm limits or measured values. Also included in this section is asummary wrap-up of the apnea settings when displaying data from aventilator device 20. The Other Measurements section displays thosemeasured values that have no related alarm limits or settings. TheAlarms section displays the current medical device alarm conditions.

Information may be accessed as a report. The reporting system providesthe maximum amount of flexibility for adding, modifying, and removingindividual reports. Reports are web pages that may require a number ofparameters such as the patient identification. The customization tablesin the database are used extensively to store navigational information.The starting screen of the report navigation is the list of availablereports obtained from the database; e.g., Snapshots, Flowsheets, Trends,Log of Events, and Log of Remote Alerts. The user is always able to getback to this starting screen by clicking on the Begin button on the topof the screen.

The customization table holds the order of report parameter web pagesfor each report. When the user selects a report, the server side usesthe customization table to determine to display either one of the reportparameter web pages or the report web page itself. These pages allow theuser to specify the value of a parameter such as patient, bed, or timerange. So if the report is only for an individual patient, the patientparameter page will display only the list of patients with theirassigned beds that have data for the report. The time range parameterpage sets both a start and end time defaulting to the last twelve hoursof data. All times are to be bounded by date range in the data itself.The user is able to directly enter dates by typing on the keyboard orclick on a set of buttons to adjust by day, hour or minute. There arebuttons to go back to the “last” twelve hours, move the range twelvehours ahead or behind. Other parameter pages may be developedspecifically for a given report. The value of each parameter is storedas a session variable on the server. The session variable also storesthe value of current “step” in the order of parameters. The current stepis decremented when the user clicks on the Back button and theappropriate parameter page is displayed.

Although the reporting system is built to be extensible, there are a fewreports considered to be standard. The Snapshot report shows a detailedsummary of the state of a medical ventilator 20 at the time of atriggering event. The user must first select a patient. Then a timerange is used to create a filtered list of snapshot reports for thepatient. The user then chooses from this list to display all of themeasured values, settings, and alarms at the time of the snapshot.

The Event Log report displays all of the important events that haveoccurred for a patient over a specified time frame. The user first mustselect a patient and time range for the report. Then there are severalspecific options for snapshot reports including different event filters,report pagination and sort order. Finally the report is displayeddetailing all of the setting changes, alarm conditions and clinicianinterventions.

The Trend report is a graphical line chart showing the movement ofmeasured values. The user first must select a patient and time range forthe report. Then the report is displayed with a separate line chart foreach trend parameter. The user can choose to magnify the size ofindividual trend parameter charts.

These reports process the raw collected data into diagnostic informationusing “smart” software. A series of institution-specific hierarchicalalarms may be viewed for each patient, in which the most critical alarmis ranked first, followed by each alarm in order of importance. As anexample, new alarms will be created that may not be present on themedical device. Such an example might consist of a high tidal volumealarm for a ventilator that does not have one built-in. Clinicians oftencompare parameters in the context of other parameters when making aclinical decision. This decision making process is encapsulated into arules-based system with the collected clinical signs and key respiratorydata as input and suggested decisions as output. The result is anindicator suggesting whether or not the patient is progressing towardsthe need for clinical intervention. These results will be combinedtogether into a triage report ranking patients by their clinicalprogress.

The administration pages are used to manage the assignment of medicaldevices to beds with patients. This administration starts with thedisplay of all current associations and the list of unassigned medicaldevices. The user will be able to click on a button to admit a patient,edit a patient, move a patient and medical device, disconnect a medicaldevice, or swap a medical device. These actions require a number ofsteps where the user will make selections. The values of theseselections are stored in session variables until it is possible toperform the action. The user will be able to cancel the action or movebackwards by one step.

The user can choose to admit a patient. The user must provide thepatient name along with an optional medical record number and comment.The user then selects the bed from the list of unassigned, availablebeds. The user selects the medical device from the list of unassignedmedical devices. The patient, bed, and medical device are all assignedto each other after these selections have been made.

The user can choose to edit the information about a patient. The usermust first select the patient to edit. Then the selected patient'sinformation will be presented in an editable format. When the userfinishes, the changes will be made.

The user can choose to dissociate the patient from the bed, where thepatient may remain in the bed but is no longer connected to the medicaldevice. Once the user selects the patient, the patient will beunassigned from the bed and medical device. This association isremembered in the database. The institution can elect to purge the datatables for this association from the database at this point or move theminto an archive database.

The user can choose to move the patient to another bed. The user firstselects the patient to be moved from a list of assigned beds. Then thedestination bed is chosen from the list of unassigned beds. The user canalso choose to swap a currently assigned medical device with anunassigned medical device. This may be necessary when preventativemaintenance is performed. The user first selects the patient to movefrom a list of assigned beds. Then an unassigned medical device isselected from the list of unassigned medical devices.

Requiring the user to log on before sensitive data is displayed on theweb pages insures patient confidentiality. There is an option button toincrease the level of data access in the administration section. A logon screen is displayed when the user requests a high data access levelfor the current web session. The logon screen requires certaininformation from the user in order to obtain patient information.

A set of monitoring pages are available specially formatted for viewingon web browsers of handheld mobile devices. The main requirement is thatthese mobile devices have small displays with tall aspect ratios. Theuser will be able to display a modified list view.

There are cases when a clinician signature is required to validate thatthe snapshot data shown on the handheld mobile device was compared tothe data displayed on the medical device 20. This requires a clinicianto be in possession of a handheld mobile device and be physicallypresent at a patient's bedside. There are special screens on thehandheld mobile device that may be viewed only by logged on users. Thesescreens on the handheld mobile device display the device data to theuser who then directly compares this data to that on the medical device.If everything matches, then the user can initiate a manual snapshot ofthe data which includes his or her signoff signature.

All of the data from the medical devices connected to a patient acquiredby the network monitoring system and reports can be storedelectronically as part of the patient's medical record. Alternatively, ahard-copy printout of the data can be included with the patient'spermanent medical record.

While the present invention has been described in terms of certainexemplary preferred embodiments, it will be readily understood andappreciated by one of ordinary skill in the art that it is not solimited, and that many additions, deletions and modifications to thepreferred embodiments may be made within the scope of the invention ashereafter claimed. Accordingly, the scope of the invention is limitedonly by the scope of the appended claims.

1-16. (canceled)
 17. A method of polling a medical device attached to anetwork, the method comprising: polling the medical device periodicallyacross the network to obtain a plurality of data values from a messagequeue for the medical device; and looping through the plurality of datavalues in the message queue, the looping comprising: obtaining the namefor each of the data values; and determining whether each data valueexists, and either creating the data value if no data value exists orupdating the data value if the data value has changed.
 18. The method ofclaim 1, comprising adjusting the medical device based on the pluralityof data values received.